<nettime> Mikki Barry: An ICANN Reform Proposal

["nettime's_roving_reporter" <nettime@bbs.thing.net>]

<http://icannwatch.org/article.php?sid=751&mode=thread&order=0>

     [via <tbyfield@panix.com>]

   The Big Picture 
   An ICANN Reform Proposal
   Posted by michael on Friday, May 17 @ 17:15:50 MDT
   Contributed by Mikki

   By its own admission, ICANN has become unwieldy, bankrupt and
   unworkable.

   This failure did not come as a surprise. ICANN has been the victim of
   an undefined mission under rules that continually change, creating a
   moving target that no corporation can hit. Unfortunately, ICANNs
   internal proposals for reform have not addressed these issues. The
   internal proposal does little for clarifying its mission, solidifying
   its rules, or even formulating a methodology for creating or changing
   these rules.

   In its current form, ICANN cannot fulfill the mandates of the White
   Paper and the consensus of the Internet community. The only course
   that will maintain the US Governments vision of privatization of the
   IANA functions will be a complete restructuring of the organization,
   beginning with its mission statement, and including every aspect of
   its operations, not limited to Board selection, supporting
   organizations, staff duties and responsibilities, public notice and
   comment, record keeping and access, and internal structure.
   Background
   The narrow technical mission of the White Paper achieved rough
   consensus in the Internet community. Such a mission would not need the
   overhead that is currently being consumed. To be specific, the narrow
   technical mission as envisioned in the White Paper would not
   necessitate nearly the structure of the current ICANN, and definitely
   would not necessitate the even larger structure that has been proposed
   by ICANN's president. The mission itself must be de-structured back to
   its original scope.

   Access to the Internet is quickly becoming the touchstone for success
   in the business world, the political world, and the world of
   individuals. In order to properly balance the public and the private
   interests in the Internet, the following changes and procedures are
   recommended:

   Mission
   The first and most important change in the structure of ICANN must
   come by carefully defining its mission. For this, we look back at the
   mandate of the White Paper, which achieved rough consensus from the
   Internet community. Four major points were enumerated as the mission
   for that "newco" would provide:

    1. set policy for and direct allocation of IP number blocks to
       regional Internet number registries;
    2. oversee operation of the authoritative Internet root server
       system;
    3. oversee policy for determining the circumstances under which new
       TLDs are added to the root system; and
    4. coordinate the assignment of other Internet technical parameters
       as needed to maintain universal connectivity on the Internet.

   This mission can more clearly be defined into three specific duties:
     * Technical parameters
     * IP Address Space
     * Domain Name Matters

   These three duties can easily be performed by three separate entities,
   each responsible for a subset of the narrowly defined mission as
   prescribed by the White Paper. The advantage to separate entities is
   that "capture" becomes less of an issue. With the proper series of
   bylaws and procedures for each entity, inclusiveness, transparency,
   accountability, and bottom-up procedures can be ensured.

   IP Numbering Authority IPNA
   The duties of the IPNA would include the following administrative and
   policy functions:
     * To act as the top level authority for delegation of IPv4 and IPv6
       address blocks. These delegations will be made mainly to regional
       address registries (RIRs) such as today's APNIC, ARIN, and RIPE.
       As has historically occurred, it is expected that there will be
       occasional delegations outside of the RIR system.
     * To maintain the top level of the in-addr.arpa (and it's IPv6
       equivalent) DNS hierarchy used for address-to-name mapping. (This
       task may be delegated to one of the RIRs if it is convenient to do
       so.)
     * To define overall policies for IP address allocations and apply
       those policies to guide the allocation of address blocks to RIRs
       and other entities.

   Technical Parameters Authority TPA
   The duties of the TPA would include the following functions:
     * To record the assignment of protocol numbers and other such values
       as specified by IETF issued documents. This job will require
       coordination with the IETF to properly perform according to the
       "IANA Considerations" of those RFCs that contain them and to
       handle those situations in which RFC guidance is absent.

   Domain Naming Authority DNA
   The duties of the DNA would include the following administrative and
   policy functions:
     * To maintain the zone file that defines the contents of the root.
       For the most part this involves maintenance of the NS records that
       indicate which DNS servers handle a particular top level domain
       (TLD) according to instructions from the entity or person who has
       the authority over that TLD.
     * To periodically publish that zone file to the operators of the
       actual root servers as well as to the public.
     * To ensure that the root servers are operated, either via the DNS
       Root Administrator itself or via an operations contract, so as to
       meet specified technical standards, perform according to specified
       service levels, and to meet certain obligations regarding security
       and physical infrastructure
     * To validate that the root server system is operating well.
     * To process requests to change the entity or person who has
       authority over a TLD according to procedures specified by the
       ccTLD Organization or the gTLD Organization, as appropriate.
     * To define what terms and conditions a ccTLD may be established or
       transferred to a new operator.
     * To define and apply the rules to establish or transfer gTLDs.
     * To define the rules to establish or transfer infrastructure TLDs
       (such as .arpa or .int.)
     * To define rules pertaining to the registration of domain names
       within gTLDs

   Implementation
   While the three entities charged with fulfilling the White Paper's
   mandates are to be legally separate and distinct, with no shared
   employees, trustees, directors, management or funds, each module must
   employ similar structures for ensuring bottom-up management,
   accountability and inclusive participation. Those structures must
   include:
     * Notice and comment periods. Notice of proposed actions will be
       announced and posted on the world wide web in sufficient detail
       and with sufficient time that interested parties may respond with
       comments. The administrator of the specific entity must evaluate
       the comments before making a final decision and must demonstrate
       that such comments have been reviewed and considered.
     * Public meetings. The public must be allowed access to the vast
       majority of meetings of the boards of any of these three entities.
       Minutes of meetings will be made available on the web in an
       expedited manner.
     * Members may vote to remove board members of any of the three
       entities.
     * Governments, as such, will not be permitted direct participation
       in any of the three entities.
     * Appeal process. An appeals process for interested parties should
       be created, for those cases where it is found that normal
       mechanisms are unsatisfactory, similar to the function of an
       Ombudsman, who has a free hand to act independently from any
       entity's board or staff.
     * Bylaws changes must require a supermajority of the board.
     * No current non-elected board members, officers, staff or trustees
       of the current ICANN will be allowed positions in any of the three
       entities for a period of five years.
     * Strict conflict of interest procedures must be implemented and
       adhered to.

   Specifics of the IP Numbering Authority
   The IP Address Policy Organization focuses on the needs and issues of
   concern to those who provide IP packet routing services and those who
   use IP addresses. This Policy Organization will be responsible for the
   creation of Policies to decide how and under what conditions address
   blocks of IP addresses should be assigned and sub-delegated. The
   output of this organization will be directives to an IP Address
   Administrator who will directly implement decided policies.

   It is expected that the staffing requirements will be minimal and
   essentially clerical. It is assumed that the job of maintaining the
   IP-to-name reverse lookup hierarchy will be delegated to the RIRs.

   Specifics of the Technical Parameters Authority
   This particular group would act as liaison to groups such as the IAB
   and IETF regarding technical implementation necessary to smooth
   operation of the Internet, simply administering the registries of
   parameter and protocol values according to the guidance given by those
   technical bodies.

   Specifics of the Domain Name Authority
   For better or worse, this will be the most complicated of the entities
   to structure, due to the inherent policy matters that are integral to
   decisions regarding top level domains, country code top level domains,
   intellectual property interests, etc. While the following structure
   may at first seem large, it is much less so than the current
   mechanisms within ICANN.

   Within the Domain Name Authority, there will be a more pronounced
   division between policy and implementation, with separate funding for
   each. We will look at policy and implementation modules separately.

   Domain Name Policy
   Within the domain naming policy module, it seems necessary to have
   separation between the gTLDs and the ccTLDs given history, differences
   in usage, difference in authorities, points of contention, etc.

   ccTLD Policy
   The ccTLD policy organization focuses on the needs and issues of
   concern to those who provide and use ccTLDs. The output of this
   organization are directives to an elected DNS Root Administrator
   regarding ccTLDs.. Such directives will generally be policy statements
   that instruct the DNS Root Administrator how to deal with requests for
   updates of ccTLD registration data - such as contact information and
   NS records.

   This policy organization will be responsible for the creation of
   policies to decide when new ccTLDs should be created, old ones
   removed, and how transfers of control of ccTLDs should be
   accomplished.

   gTLD Policy
   The gTLD policy organization focuses on the needs and issues of
   concern to those who provide and use gTLDs. The outputs of this
   organization are directives to an elected DNS Root Administrator
   regarding gTLDs.

   This policy organization will be responsible for the creation of
   policies to decide when and how new gTLDs should be created, how
   control is transferred, and the like.

   There will be great pressure for this policy to engage in policy
   making about things that go beyond how the ICANN DNS root and its
   contents should be managed: We are likely to see pressures to create
   trademark related policies and registry/registrar business operation
   policies.

   To avoid many of the pitfalls that spelled failure for the original
   ICANN, it is recommended here that the gTLD Policy Organization have
   explicit limitations in its organic documents to constrain the degree
   to which it may engage in what amounts to Internet lawmaking. And
   policies regarding business practices should be similarly constrained
   except for those needed to ensure that any failed DNS registrar or
   registry maintains enough recoverable assets and information so that a
   successor may pick up the pieces and resume services to the customers
   of the failed entity.

   Administration of DNS Policies
   The DNS Root Administrator oversees the operation of a DNS as
   previously listed. The DNS Root Administrator will be responsible for
   the establishment of operational policies regarding the operation of
   the root servers. These policies will be established through a notice
   and comment process

   The ccTLD policy organization will promulgate appropriate procedures.
   It is anticipated that the policies regarding the recognition of new
   ccTLDs and the re-delegation of existing ccTLDs will be the most
   complex and, at least initially, may require a close working
   relationship between the ccTLD policy organization and the DNS Root
   Administrator.

   The gTLD policy organization will promulgate procedures for the DNS
   Root Administrator with respect to gTLDs. The gTLD policy organization
   will issue directives to the Root Administrator to create or remove
   gTLDs.

   It is expected that the DNS Root Administrator will operate the DNS
   root servers initially via the loose federation of entities and
   individuals listed via http://root-servers.org.[1] However, over time 
   the DNS Root Administrator may chose to take a more direct role and
   operate some or all of its root servers itself.

          [1] http://root-servers.org/

   The DNS Root Administrator function will require staff and computing
   resources. Several of its jobs - such as monitoring the performance
   and availability of DNS root servers - may be contracted out. As with
   each module of each authority segment, technical requirements must be
   in balance with fiscal responsibility.

   Domain Name Rights Coalition
   www.domain-name.org
   Email: admin at netpolicy dot com.


#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net